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BACKGROUND 


In 1981, Amateur packet radio was highly experimental. As late as 
1984 there were serious questions of packet's viability as a useful 
mode in Amateur radio. 


The early days of the packet revolution were filled with digital zea- 
lots proclaiming the virtues of the new mode. Their fervor spread, 
and Amateurs by the thousands climbed aboard the bandwagon. In 1989, 
with well over 100,000 TNCs in daily use in Amateur stations around 
the world, there is no doubt that packet is here to stay. 


The question now? 


Is packet to be useful to Communicators, or will it remain in the do- 
main of the Techies? 


YESTERYEAR'S PACKET PIONEER 


In 1983, the TAPR Beta test demonstrated that groups of Amateurs, 
given operable equipment, could use packet on VHF to send data within 
a local group. It also demonstrated that a local group was necessary 
to assure sufficient technical know-how in getting packet stations on 
the air. 


PACLEN, MAXFRAME, TXDELAY and DWAIT became bywords. Arguments raged 
regarding the interpretation of <CR>_ and <AUTOLF>. Manuals included 


lengthy appendices describing the intricacies of Level Two protocol. 
Anyone who didn't know the difference between hardware and software 
HDLC simply wasn't educated, and everyone who thought they did know 
would immediately jump on the channel and discuss the issue! 


Hours were spent at club meetings and hamfests across the land descri- 
bing the wonders of bit-stuffing, the magic of transparency and the 
evils of excessive packet overhead. 


WINDS OF CHANGE 


When TAPR marketed TNC kits (1983 through 1985), the first units were 
grabbed up and built by the techies. There were questions to answer 
and technical support to provide, but by and large the folks who 


92 


bought and built the early TNCs were able and willing to wade through 
hundreds of pages of documentation to configure and operate their 
packet stations. 


Towards the end of the kitting experience, however, a definite trend 
emerged. More and more people were buying and building the kits, but 
not understanding the complexities of the TNC hardware and firmware. 
Kits were sent in for repair that had been improperly soldered and 


with sometimes gross errors in assembly. Questions were being asked 
that reflected inexperience in computing and data communications 
concepts. Many questions demonstrated a lack of understanding of 


basic commands and timing relationships of the AX.25 protocol. 


TODAY'S PACKETEER 


Many Amateurs today are not particularly technically inclined. This 
is neither good nor bad; it simply is. 


It is useless to bemoan the bygone days of home-brew equipment. To- 
day's bands are too crowded for efficient work with a spark gap trans-— 
mitter and coherer detector. 


Many people try HF packet and give up. They blame the demodulator (or 
the zealot who told them it was possible), 


Many digipeaters and single-port network nodes are on hilltops with 
omnidirectional antennas. Folks who try to get through using these 
systems claim, "Packet doesn't work!" They blame the mode and ignore 
the practical impact of the implementation of the mode. 


We live in a generation which requires illustrations rather than 
words; simplified explanations rather than rigorous -understanding. 


The purpose here is not to belittle or condemn, The point is simply 
that many people now getting on packet are not technical people. 
Packet is not the end, but simply a means to other ends. These folks 


simply wish to communicate. 


YESTERYEAR'S PACKET EQUIPMENT 


Early automobiles required mechanical aptitude to operate. You had to 
set the spark, hand-crank the _ engine, patch the tires, adjust the 
throttle, squeeze the horn, double-clutch when shifting, wear goggles 
and tolerate the weather. 


For this effort, you were rewarded with the ability to exceed 15 miles 
per hour and go uphill in reverse gear only. 


Early packet equipment included numerous commands to configure the TNC 


to every conceivable type of terminal or computer. The user had to 
understand the meaning of NULLS, ASYNC PORTS and so on. 
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Manufacturers entering the packet fray struggled to outdo each other 
in advertised number of commands. Simpler equipment included non- 
mnemonic commands and required the user to not type when the _ radio 
channel was. busy. 


Yes, early packet gear was troublesome to interface and difficult to 
understand. 


TODAY'S TNCS AND MULTI-MODE CONTROLLBRS 


Today's automobiles include climate control, compact disc audio sy: - 
terns, power sun roofs, automatic transmissions with overdrive and 
speech synthesized messages to tell you to add water to your 
windshield washer's reservoir. 


Today's TNCs include numerous commands to configure the TNC to every 
conceivable type of terminal or computer. The user has to understand 
the meaning of NULLS, ASYNC PORTS and so on. 


Manufacturers struggle to outdo each other in advertised number of 
commands, 


Multi-mode controllers are even worse, often with literally _hundreds 
of commands. 


Yes, early packet gear was troublesome to interface and difficult to 
understand. Today's packet gear is more troublesome and difficult. 


Progress nowadays means providing on-screen menus to crowd the myriad 
commands into little boxes that you can point to and alter. Organiza-— 
tion may be better; a user's technical understanding requirements are 
at least as bad if not worse. 


CAN WE IMPROVE THE SITUATION? 
Allow me one last comparison. 


Many folks today go out and purchase an MS-DOS computer. With an in- 
stalled base of over 10 million units, you'd think the industry would 
be able to cater to the casual user. 


Not so. 


If you are a techie, you have undoubtedly been asked by people to help 
them set up their computer or format their hard disk so they could use 


their database or spreadsheet or word processor. In other words, 
these folks are interested in _using _the _computer’. They are not 
interested in the theory and operation of computing. The computer is 


a tool; the application program is the reason for obtaining the 
computer. 
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In the same light, it is my contention that many people getting on 


packet today couldn't care less about bit-stuffing and _  HDIC. They 
simply want to send data reliably from point A to point B. The mech- 
anics of how the data gets there is of no interest. The mode is a 


means, not an end. 


For these people, it is unreasonable to expect them to learn of the 
intricacies of Level Two (or higher) protocol. They drive cars with 
automatic transmissions. They don't want to have to use a clutch to 


send data. 


SUGGESTIONS FOR THE 90S 


In the 1990s, Amateur packet gear needs to be built for communicators. 
Command sets ought to be simplified, and the microprocessor should 
make many of the decisions now required by the user, 


For example, the user's serial port, which connects to his computer or 
terminal, needs only the following options: 


Data rate (baud), word length and parity. 


Data rate can be automatically detected and retained. Word length is 
one of two choices. Parity is tied to word length, with even parity 
for 7 bits and no parity for 8 bits. The user now has to make only 


one decision (word length/parity). 


Historically, TNCs were used with mechanical ASCII terminals running 
at 110 baud. (If someone really wants to run an antique like this, 
they can just as easily run an antique TNC that allows NULLS, odd 
parity and so _ forth!) 


Almost everyone on packet nowadays uses a personal computer of some 
sort, The software in the personal computer allows setting up data 
rates, word length, parity, etc. So, rather than force the user to 
make several selections at both ends of the serial line, make the TNC 
a limited subset, then clearly document the _ subset, 


Most telecomm programs default to 7 bits, even parity, 1200 baud. The 


TNC should match these defaults. Use of 8 bits and no parity may be 
easily selected for sending binary data. By careful selection of the 
key the user strikes to establish the data rate (carriage return, for 
example), parity can also be auto-detected. The user then has to make 


no selections regarding the serial port. 


Other areas of simplification could involve the user telling the TNC 
how he is using the TNC, rather than specify everything to the TNC in 
exhaustive detail. 


For example, the user could tell the TNC he is operating on HF, or 


VHF/FM or Satellite. The TNC would then set the TXDelay, FULLDUP, 
DWAIT, DIGIPEAT, MAXFRAME, PACLEN and other parameters to reasonable 
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defaults. If VHF/FM, the user could further specify whether a 
repeater was to be used, allowing setting of AXDelay and AXHang. 


A first step in this direction has been taken by AEA in their PK-88 


and PK-232 systems. If the user invokes the KISS command (SLIP 
protocol), system defaults are altered to automatically adjust to this 
environment. 


A number of timing and other "link" parameters can be fully automated 


rather than simply auto-defaulted. For example, the MSYS_ packet 
bulletin board system software watches retries and alters PACLEN 
dynamically. See my paper on _Thoughts _on an Adaptive Link Lev: 1 


Protocol elsewhere in these proceedings for some ideas in this regard. 


CONCLUSION 


The purpose of this paper is to get people thinking about command 
structure simplification for packet radio controllers. Packet has 
grown from a newborn to adolescence. Whether it becomes a useful mem-— 
ber of our Amateur communications society, or a merely ne’er-do-well 
of great potential, depends on how well its implementations match the 
user community that will apply it to solving communications problems. 
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